<html>
<body>
Reports expressions that can be replaced by a call to the <code>Integer.compare()</code> method or
a similar method from the <code>Long</code>, <code>Short</code>, <code>Byte</code>, <code>Double</code> or <code>Float</code> classes,
instead of more verbose or less efficient constructs.
<p>If <code>x</code> and <code>y</code> are boxed integers, then <code>x.compareTo(y)</code> is suggested,
  if they are primitives <code>Integer.compare(x, y)</code> is suggested.</p>
<p><b>Example:</b></p>
<pre><code>
  public int compare(int x, int y) {
    return x > y ? 1 : x &lt; y ? -1 : 0;
  }
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
  public int compare(int x, int y) {
    return Integer.compare(x, y);
  }
</code></pre>
<!-- tooltip end -->
<p>
  Note that <code>Double.compare</code> and <code>Float.compare</code> slightly change the code semantics. In particular,
  they make <code>-0.0</code> and <code>0.0</code> distinguishable (<code>Double.compare(-0.0, 0.0)</code> yields -1).
  Also, they consistently process <code>NaN</code> value. In most of the cases, this semantics change actually improves the
  code. Use the checkbox to disable this inspection for floating point numbers if semantics change is unacceptable
  in your case.
</p>
<p><small>New in 2017.2</small></p>
</body>
</html>